Suppose you have several files that  "go together", in the sense that  none
is particularly useful without the others.  For instance, you might have  a
data file and  the program  that processes  it.  You  might have  a set  of
source files (the three source and data files for Adventure were one of the
inspirations here).  You might have a set of related programs that you want
to archive (say, on Dart tape), and  you'd like to be able to retrieve  the
whole set as a unit.  Well, BUNDLE is the program for you!

When you  run  BUNDLE, it  asks  for  various parameters  (described  in  a
moment), and creates a  "personalised" program that will  act as a sort  of
shell surrounding one or more arbitrary files.  The first time you run this
personalised program, it  will read  in the file(s)  you've specified;  you
should then save the core image  using the SAVE command.  Thereafter,  when
you run  the program,  it will  write the  stuff back  into the  individual
files.  It will also (optionally) print a message of your choice, which can
be used to  describe how  to use the  files.  Perhaps  most important,  the
unbundling program will finish by (optionally) executing an arbitrary SNAIL
command, such as  EXECUTE, RER, or PROCESS.  A typical  use of the  command
would be a PROCESS or RER command to run PACK to un-compress the files just
written, or to invoke  DO to execute  one of the  newly-written files as  a
longer sequence of commands.  ("DO" is not itself a SNAIL command.  You can
also invoke DO or PACK  or whatever via the  RER and RERUN commands,  which
ARE handled by SNAIL.)

Note that there  are therefore three  "stages" of a  bundle.  This can  get
somewhat confusing, so let's  go over them once  more.  The first stage  is
BUNDLE.DMP[1,3], the  unpersonalised form  that  you should  never  change.
When you run it,  it gets from you  the specifications for your  particular
application, then throws away the initialisation code (to save space),  and
provides you with  the second stage;  at this point,  the program has  been
personalised to your task, but has not actually read in any files yet.   As
part of  initialisation, you  can specify  that this  second-stage  program
should be run at once,  or you can wait until  later if, for instance,  the
files aren't yet available to be "absorbed".  When the second-stage program
is executed, it  reads in  the files and  leaves you  with the  third-stage
program, which is  what you actually  want.  This final  form is what  will
write the files back out and execute the SNAIL command.

It's suggested that, when you save the third-stage program, you  explicitly
specify some  extension (other  than DMP),  to identify  the program  as  a
bundle.  You can  still run it  with the  RUN command by  again giving  the
explicit extension.  A good extension might be BUN.

Now, some details.

First, be warned that the  files to be read/written  MUST be on your  alias
directory when read, and will be written on your (possibly different) alias
directory when restored.  In other words, you can't specify a bracketed PPN
with the file  names.  Nor  can you  specify a  device; the  files are  all
assumed to be on  device DSK.  Anyhow,  when you say  R BUNDLE, you'll  get
told briefly what's going on,  and then you'll be asked  to give a list  of
file names, one at a time, ending  with a blank line.  You have to  specify
at least one file; it's assumed that there's not much point in using BUNDLE
just to print a message and execute a command (you could use DO for that!).
After you end the file list, you're asked to type in whatever message you'd
like the bundle to print when the third-stage program is run.  This message
can be null, or it can be  several lines.  (The actual limit is about  5000
characters.)  Terminate it with an ALTMODE.  Finally, you're asked for  the
SNAIL command.  Type it just as you would to the system, e.g.,

LOAD/SAVE MUMBLE.SAI,SUBR1.FAI,SUBR2.FAI

or

PROCESS ↔R PACK↔UFOO.PAK↔FOO.SAI↔EEX FOO↔

ending with a carriage return.  If you give a blank line, SNAIL will not be
invoked at all.

Finally, you'll be asked whether or not the second-stage program should try
reading the files right away; if not, the program will exit when it reaches
the second stage, and you can save  it and run it later when you're  ready.
Note that, if you tell it to try reading the files and it bombs out because
one or  more of  the files  is missing,  all is  not lost.   Just save  the
program and run it  again later; the  error exit does  not do any  internal
damage!

When the third-stage program is run, if any of the files it wants to  write
already exist, it will  ask for confirmation  before overwriting each  one.
The arbitrary message  (the one  terminated with altmode)  will be  printed
before any  of  the files  get  written; the  SNAIL  command of  course  is
executed only after all the files have been successfully restored.

Note that you  don't actually  save any words  of disk  space by  bundling,
since the  resulting file  contains all  the original  files plus  a  small
amount of program.  You might  nevertheless save some disk "tracks",  since
every file is allocated in units (tracks) of about 2300 words.

Once the program has reached the  second stage, it is impossible to  change
the list of  files or the  message or the  SNAIL command.  If  you need  to
modify these things, you'll have to start over with R BUNDLE.  However,  it
IS possible to update the files stored within the third-stage bundle.  That
is, once you've read in the files, it is still possible to re-read them  so
as to store a more  up-to-date version of the files.   To do this, use  the
GET command to  load the third-stage  bundle into core,  and then  REENTER.
Note that it's hard to  really screw yourself with  this feature -- if  you
meant to write the files instead  of rereading them, you simply decline  to
save the new core image after reading,  and if you meant to read the  files
and forget to do the REENTER, you won't overwrite the existing files  until
you've been given a chance to abort (and after aborting you can just do the
REENTER right away).

If you want to find out what a bundle contains, use the GET command to load
it into  core, and  then  type START +1.   You'll  be  told what  files  it
contains (or will  contain, if it  hasn't read them  yet), what message  it
prints, and what SNAIL command it executes.

One last note:   If all goes  well, this  will never concern  you, but  you
should know that the  bundler computes a checksum  of itself and the  files
when it  reads in  the  latter, and  later  verifies this  checksum  before
writing the files.  If  you get the  message, "Checksum failure!",  there's
probably been a transmission error in  moving the BUN file around.  If  you
choose to proceed despite the checksum error, be wary!

Finally, for a similar facility that is somewhat more general but (in  some
ways) less convenient, READ SPINDL.